Let me quickly explain why I raised the minimum pandas version here: since we're using pandas for the upsert-functionality of parameter.add_data(), the workflow is like this:

        # Gather all indexsets/columns
        index_list = [column.name for column in parameter.columns]
        # Convert existing data to DataFrame
        existing_data = pd.DataFrame(parameter.data)
        # Set the index to be constructed as each "key", i.e. row of indexset-values
        # This allows quick comparison of keys for existence and only updates what we actually want to update, i.e. values and units.
        # Can't do that for empty dataframes, though (i.e. first addition of data to a parameter)
        if not existing_data.empty:
            existing_data.set_index(index_list, inplace=True)
        # Upsert the new data
        parameter.data = (
            data.set_index(index_list).combine_first(existing_data).reset_index()
        ).to_dict(orient="list")

I don't see any issue with that code, but pandas < 2.1.0 does: if existing_data is empty, we can't set an index on it. But if the indices of the two dataframes in combine_first() don't at least overlap, pandas doesn't know how to combine them.
In our case, this should not be an issue, though: existing data will always have the same multiindex as new data, we validate all data to ensure precisely this. The one exception, of course, is if existing_data is empty, but in that case, pandas should just take all values from the new data and don't bother about upserting -- which it does, but only as of 2.1.0.
This version was released a year ago, so I'm fine with bumping our minimum version. If you have a better idea of how to resolve this, I'm happy to hear it, too :)

(Going to make exactly the same commit on #97 and #98, too.)

Thanks for the review :)
I agree that a lot of code seem to be boilerplate, which is one of the reasons I opened #96. So I'm happy to help with some refactoring, if I can :)

I would likely merge this PR then, if you change your review to "approve", as @danielhuppmann doesn't seem to have enough time to review it. No one will immediately start using it, anyway, so I think the most time-efficient version for @danielhuppmann is to review #101 and/or #108, which showcase most of the added syntax. If this is not to our liking, we can still introduce clean-up PRs before merging the tutorials to main.
Besides, I've tried to make the syntax consistent with what we already have, so I think it's unlikely that there are major problems hiding in there.

Finally, @meksor, may I recommend reviewing #97 and #98 soon, too, if time permits? Both PRs are similar to this one and even more so to one another, so doing it soon would keep you from having to chew through all the boilerplate again as you probably still remember the parts that are important.